1章 信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション

アプリケーションで必要な機能

データベース

キャッシュ

検索インデックス

ストリーム処理

バッチ処理

1. データシステムに関する考察

データシステムにおける需要な課題

信頼性

システムは障害があったとしても正しく動作するべきである。

スケーラビリティ

システムの成長に対して無理のない方法で対応するべきである。

メンテナンス生

システムに関わる多くの人が生産的に関われるようにするべきである。

2. 信頼性

信頼性とは「何か問題が生じたとしても正しく動作し続けること」

問題を起こしうるものはフォールト（fault）と呼ばれる

フォールトの存在を見越して対処できるシステムは耐障害性を持つ（fault tolerant）

Chaos Monkyのような意図的にfaultを引き起こしてテストを行うアプローチがある。

1. ハードウェアの障害

データ量やアプリケーションで求められる処理量に比例してハードウェアのfaultの発生率も増大する

ハードウェアの冗長化だけでなくソフトウェアによる耐障害性への手法によって、マシン全体が失われても耐えられるシステムを構築できる。（ex:ローリングアップグレード）

2. ソフトウェアのエラー

ソフトウェア障害を引き起こすようなバグは長い間潜伏していることがよくある。それはそのソフトウェアが動作環境で何らかに前提を置いてあるが、その前提が何らかの理由で正しくなくなる。

手っ取り早い解決策は無い。

3. ヒューマンエラー

人間には信頼性がない。（最も多いサービス障害の原因はオペレーターによる設定エラー）

エラーの可能性が最小限になるようシステムを設計する。

サンドボックス環境を用意する。

徹底的なテストと自動化

テレメトリ

3. スケーラビリティ

負荷の増大に対してシステムが対応できる能力のこと

1. 負荷の表現

負荷のパラメータによって表現できる

webサービスなら毎秒のリクエスト数、データベースの読み書き比率、同時アクティブユーザー数、キャッシュヒット率など

2. パフォーマンスの表現

負荷が増大した時に起こることの調査方法

負荷のパラメータを増やしながら、システムのリソースを一定に保った場合のシステムのパフォーマンスの影響

負荷のパラメータを増やした時にパフォーマンスを保つためにどれだけのリソースを増やさなければならないか

サービスの典型的なレスポンスタイムを知りたい場合はレスポンスタイム順にソートして中央値から判断する。

パーセンタイルから外れ値がどれほど悪いかを知ることができる。

大きなパーセンタイルのレスポンス値（テイルレイテンシ）

サービスレベル目標（SLO: Service Level Objectives）やサービスレベルアグリーメント(SLA)に利用される

ヘッドオブラインブロッキング(head-of-line blocking)

サーバーが同時に並列処理できる数は少ないので、低速なリクエストが少数あるだけでそれ以降のリクエストの処理が待たれること

クライアントから見れば以前のリクエストの処理が完了するまでの時間によって全体のレスポンスタイムは大きくなってしまう

3. 負荷への対処のアプローチ

シェアードナッシング(shared-nothing)アーキテクチャ

複数の比較的小さなマシンに負荷を分散させること

4. メンテナンス性

運用性

運用チームが扱いようにする

単純性

システムから複雑性をできる限り取り除く

進化性

拡張性、修正の容易性、プラスティシティ(plasticity)